第2章 コミュニケーションと言語の使い方
共通言語を使っていくぞ、という話
ドメインモデルはソフトウェアプロジェクトにおける共通言語のコアとなることができる モデルは、頭の中で構築された概念の集まりで、ドメインについての洞察を反映した用語と概念間の関係性からできている
この用語と相互関係は技術的な開発ができるくらい正確
モデルを最大限に有効活用するには、コミュニケーションのためのあらゆる媒体にモデルを浸透させる必要がある
ドキュメント、雑談…
しなやかで知識豊富な設計を行うには、用途の幅広い、共有されたチームの言語と、そ の言語を使った活発な実験が必要である。
ドメインエキスパート(Exp)と開発者(Dev)の言語の断絶
Exp
技術的専門用語が部分的理解。自分の得意分野の専門用語を様々なニュアンスで使用。
Dev
機能に関する説明的な用語を用いる。（Expの言語が持っていた意味を欠く）
Devによる抽象化は、設計を支えていても、Expには理解されないかも。
別の部分に取り組んでるDevはそれぞれで考えてしまう
言語の断絶で起こること
コスト＋誤解のリスクが生じる
Exp-Exp間、Exp-Dev間、Dev-Dev間での通訳
通訳はコミュニケーションを鈍らす。
通訳は知識の噛み砕きを沈滞させる
日々の議論とコードの用語が一致しない。
話し言葉と書き言葉で一致しない。
誰の言葉も共通言語になれない
共通言語が必要→ドメインモデルがその基盤となれる
takkii.icon 言語の断絶は起きているか？
ユビキタス言語の語彙
クラス、主要な操作のなまえ
云々
ユビキタス言語（モデルに基づいた言語）の使われ方
Exp-Exp間、Exp-Dev間、Dev-Dev間
タスクや機能の記述
要件や開発計画
↑最低ライン
初めはこの役割を果たせるほど、モデルが優れてないかも
モデルに基づくこの言語に対し、チームが献身することが大事
粘り強くユビキタス言語を使う
→モデルの弱点がわかる
→言語の変更を行う。そしてそれはドメインモデルに対する変更となる
→チームでクラス図を更新したりする
ドメインエキスパートのすること
モデルが対象とするスコープの中ではユビキタス言語を使用すべき
誤っていると思った場合は指摘すべき。
モデルを言語の骨格として使用し、その言語を厳格に用いることをチームで決断しよう
14章では複数のモデルが存在する場合を取り上げる
例2.1 貨物輸送プログラムを完成させる
シナリオ 1 :ドメインに対する最小限の抽象化
シナリオ 2 :議論を支えられるように豊かになったドメインモデル
シナリオ2の方がドメインモデルが充実しており説明も明確
声に出してモデリングする
人は話すときドメインモデルの言語を使わない
モデルを改良する最適な方法の1つは話してみること。
荒削りな表現は聞けなすぐわかる
モデリング作業には、視覚的・空間的な思考を駆使するのと同様に言語能力を活用するのも大事
ユビキタス言語を議論で使用すると、全員がその言語で話せるようになり、ニュアンスを互いにおしえあう。
図とドキュメントでは起こりえない。
1つのチームに1つの言語
開発者はドメインエキスパートをドメインモデルから遮断しようとすることもある。
その言い訳
「彼らには抽象的すぎる」
「オブジェクトがわかってない」
「彼らの用語法に従って要求を集めなければならない。」
豊富な知識を持つドメインエキスパートがモデルを理解できないとしたら、モデルに何か問題がある。
最初（システムが将来持つがまだモデル化されてない機能について）
ユーザと開発者が手探りで進めていく
ドメインエキスパートはその言語を身につけ、古いドキュメントを修正していかなくてはいけない
議論するとドメインエキスパートが自分たちの思考の矛盾やあいまいさがあることに気づける。
開発者・ドメインエキスパートが互いに相手にわからない技術用語を使用することは確かにある
Dev側：システムの技術的な専門用語
Exp側：アプリケーションのスコープ、開発者の理解を超えた専門用語
言語が拡張されたものでしかない（そうあるべき）
同じドメインに関して異なるモデルを反映していてはいけない
左が開発者、右がドメインエキスパート
https://gyazo.com/264d685cb8b2d5801b3bc379e53c5b87
ドキュメントの話
ドキュメントと図
筆者は会議中にUML図、クラス図、オブジェクト図を書くことが多い。
図を書くことである種の情報は把握しやすくなる。
オブジェクト間の関係性など
しかし、オブジェクトの概念的な定義は伝わらない。会議の会話のなかに現れる。
図を書くことで議論が効果的になり、図を変更することもできる。この移り変わりが議論の真髄。UMLは統一モデリング言語の略である。
問題が発生するタイミング
モデルや設計の全体を伝えるのに、「UMLを使うことを強いられている」と人々が感じた時
人々はコーディングしようとしているオブジェクトを全てモデリングツールに描かなくてはと思いがちだがそんなことはない。
属性と関係性は図示できても、オブジェクトの振る舞い・オブジェクトに対する制約はそれほど簡単に図示できない。
UML図はモデルの重要な側面のうち、
モデルが表している概念の意味
オブジェクトが何を行うことになっているか
を伝えられない。
だが、自然言語がその役割をこなせる
UMLはプログラミング言語としてもそれほど満足できるものでもない。
整然としたモデルを伝える別の手段がやはり必要
図はコミュニケーションと説明の手段。
図はモデルを簡略化し、説明するもの。
あらゆる詳細についての設計仕様書ではない。
図が表現しているのは考え方の骨格
設計に関する本質的な詳細は、コードにおいて捉えられる
適切な実装は透過的で、根底にあるモデルを明らかにする（次章、本書の大部分）
図とドキュメントはみんなの注意を要点に導ける。自然言語の議論で、意味のニュアンスを補うことができる。
図にテキストで注釈を加えるのではなく、テキストを書いた上でシンプルな図で説明する
モデルは図ではない。図の目的はモデルの説明を助けること。
takkii.icon 会話、図、コードの役割分担を意識するといいのかな。
takkii.icon 最近、図を用いたことはあるだろうか？図を用いた方が良かった場面はあるか？
口頭でのコミュニケーションによって、厳密で詳細なコードに対して意味が与えられる。
書かれたドキュメントが安定し共有可能であることも必要。
しかしそれを書くのは難しい。
ドキュメントはコードの進化、言語の進化からおいてかれてしまう
この問題へのアプローチは色々ある。ここではドキュメントを評価するための一般的な指針を2つ提案する
1つ目の指針：ドキュメントはコードや会話での表現を補わなければいけない
各アジャイルプロセスはドキュメントについて独自の哲学を持っている。
コミュニケーションの媒体としての機能をコードに頼れば、開発者はコードをクリーンで透過的に保とうとする。
しかし設計ドキュメントとしてのコードにも限界はある。
振る舞いに曖昧なところがなくても、理解しやすいということではない。
口頭で補えるが短命・局所的。
開発者以外もモデルを理解できる必要
コードがうまくやっていることをドキュメントでもやろうとすべきでない。
書かれたドキュメントはコードと会話を補足すべき
意味をはっきりと説明し、大規模な構造への洞察を与え、コアとなる要素に意識を集中させる目的を持つこともある
プログラミング言語が概念を直接的に実装できない時に、ドキュメントで設計の糸を明確にしたりする
2つ目の指針：ドキュメントは活動の役に立たなければならず、最新の状態を保たなければならない
手描きの図は「形式張らないその場限りのもの」という印象を与えるという利点がある
設計ドキュメントのもつ最大の価値は、
モデルの概念を説明すること
コードの詳細を描き進める上で役に立つこと
モデルで想定されている使用方法について多少の洞察を与えること
ドキュメントはプロジェクトの活動に取り込まれていなければいけない
その確認方法は「ユビキタス言語とドキュメントとの相互作用を観察すること」
設計ドキュメント内の用語が会話とコードに出てくるか？
ユビキタス言語が変化しているのにドキュメントが取り残されていることも
ドキュメントを最小限にとどめ、その焦点をコードと会話の補足に絞ることで、ドキュメントがプロジェクトに結びつけられた状態を保つことができる
takkii.icon 既存のドキュメントでこの指針がいきそうなものはあるか？
XP(エクストリームプログラミング？)やその他のコミュニティによる選択肢の検証
実行可能なコードとそのテストに依存する
本書の大部分はモデル駆動設計を通じてコードに意味を伝えさせる方法を論じている。
正しいことを「する」だけでなく、正しいことを「言う」コードを書くためには潔癖でなければならない
ふるまいと表現の間の食い違いを取り除くことが「宣言的設計」（第10章）
一般的にうまくいかない
誤解を招くことがあるとはいえ、他のドキュメントよりもコードは根本に近い
実装、設計、チーム内のコミュニケーションの根底にあるモデルは1つであるべき。これらのそれぞれの目的のために別々のモデルを持つのは危険。
「設計を推進するモデル」とは別に「ドメインに関して説明するためのモデル」を持つのは良い。
「説明のためのモデル」は通常オブジェクトモデルでない方が良い。「推進するモデル」と正確に同じになることは滅多にない
クラス図（推進のための図）と説明のための図を一緒に見た方が理解しやすくなる
自然言語を用いた説明と合わせることで、より厳密なモデル図を理解できる
takkii.icon これは「モデル」なのか。具体例では？（わかりやすいのは同意）
モデルは、頭の中で構築された概念の集まりで、ドメインについての洞察を反映した用語と概念間の関係性からできている